Context

Follow-up to #74. That PR moved AttributeHandlerRegistry to a robust, symbol-based DateTime/DateTimeOffset check, but UnixTimestampTypeHandler.CanHandle was left on the brittle name-only comparison:

underlyingType.Name == nameof(DateTime) || underlyingType.Name == nameof(DateTimeOffset)

A user-defined type named DateTime (or DateTimeOffset) outside the System namespace would be mistaken for the BCL type.

Change

• Extract the robust check into a shared ITypeSymbol.IsDateTimeOrDateTimeOffset() extension (SpecialType.System_DateTime for DateTime; type name + System namespace via ToDisplayString() for DateTimeOffset, which has no SpecialType).
• Use it in both UnixTimestampTypeHandler.CanHandle and AttributeHandlerRegistry — single source of truth, removes the duplicated namespace logic.

Scope notes

Deliberately left untouched (out of scope of this finding):

• UnixTimestampTypeHandler.GenerateFromDynamoRecord name checks — they run only after CanHandle already confirmed the type, so they select a branch rather than gate.
• DateTimeTypeHandler / UnixTimestampAttributeHandler name-only checks — pre-existing, unrelated to this finding. The new extension is available to tighten them later.

Validation

• dotnet build of the generator: clean (0 warnings/errors).
• dotnet test: 359 passed, 0 failed — including a new regression test that builds a type named DateTime outside System and asserts CanHandle returns false (would have returned true under the old check).